Lab 7 · 残す行を選ぶ

UniLearnの学籍システムとLMSには、同じ学生IDが含まれていません。チームはいくつかのレポートを必要としており、それぞれが次の問いに対して異なる答えを持ちます。 「どのソースの行を含めるべきか？」

Lab 6のデータベースを再利用する

Lab 6で lab6_7_setup.sql をすでに実行している場合は、そのデータをそのまま使用してください。そうでない場合は、チューターから提供された共有セットアップファイルをpgAdminで開き、一度実行してください。新しいQuery Tool接続ごとに次のスキーマを選択してください。 lab6_7 を選択してください。

理解している結合から始める

確認する: students および lms_roster（学籍システムに22件のID、LMSに6件のID）。
Lab 6の照合ルールで使用したINNER JOINを実行する。
両方のソースに存在する4つのIDを特定する。
この結果がどちらのソースの完全なリストにもなり得ない理由を説明する。

5つのレポート要求

共有アカウントの一覧、すべての学籍学生の保持、すべてのLMSアカウントの保持、両ソースの突合、学生とコースの組み合わせの生成。これらの要求に対して、INNER、LEFT、RIGHT、FULL、CROSS JOINクエリを作成します。

✍️ 欠落しているコンテキストを予測しよう

S103は学籍に登録されていますが、LMSアカウントを持っていません。S901はLMSにインポートされていますが、学籍に存在しません。完全なレポートでは、それぞれどこに含まれるべきでしょうか？

SET search_path TO lab6_7;

SELECT s.student_id AS registry_id, s.student_name,
       r.student_id AS lms_id, r.lms_name
FROM students AS s
INNER JOIN lms_roster AS r
  ON s.student_id = r.student_id
ORDER BY s.student_id;

一致したIDを確認する

4行: S101、S102、S105、S121。各IDは両方のテーブルで一意であるため、一致したペアはそれぞれ1回ずつ表示されます。このレポートには共有アカウントのみが含まれます。

Uma（S121）は履修登録がないにもかかわらず、LMSアカウントを持っています。アカウントが一致することは、コースへの参加を証明するものではありません。

両方のソースを確認する

LMS名簿は検証されていないインポートです。studentsへの外部キーが意図的に設定されていないため、S901とS902はそのソースにのみ存在できます。

SET search_path TO lab6_7;

SELECT student_id, student_name
FROM students
ORDER BY student_id;

SELECT student_id, lms_name
FROM lms_roster
ORDER BY student_id;

LMS ID	LMS名	学籍にあり？
S101	Alice Wong	はい
S102	Ben Lau	はい
S105	Emma Li	はい
S121	Uma Shah	はい
S901	インポートされた訪問者A	いいえ
S902	インポートされた訪問者B	いいえ

共有セットアップには、以降のタスク用に8件のコース、37件の履修登録、8件の課題、30件の提出物も含まれています。すべてのレコードは架空のものです。

結合を選ぶ前に要求を読み取る

要求	必要な結果
共有アカウント	一致するIDペアのみ。
学籍のカバレッジ	LMSアカウントがなくても、すべての学籍学生。
LMSインポートの監査	学籍との一致がなくても、すべてのインポートされたLMSアカウント。
両システムの突合	共有アカウント、およびいずれか一方のソースにのみ存在するレコード。
コース計画	選択されたすべての学生と、選択されたすべてのコースの組み合わせ。

Lab 6では、一致するペアがどのように行を形成するかを学びました。このラボでは、結合タイプを変更して、一致しない行を制御したり、すべての組み合わせを生成したりしたうえで、各結果行が何を表すかを確認します。